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TITLE: System and method of administering, tracking and managing of claims 
processing 

Summary of Invention Paragraph : 

[0010] Loss appraisal involves loss assessment and related activities. In most 
automobile insurance claims, the damage assessment is developed using computerized 
damage estimating software. However, conventional computerized estimating platforms 
utilize incompatible proprietary data and communications formats. Most carriers 
lack the ability to electronically integrate data from multiple systems, and 
therefore encourage or require their affiliated repair facilities members to use a 
specific estimating platform so that the data generated can be analyzed and 
compared to the results of other estimating resources used by an insurance carrier. 
In order to communicate with different carriers, repair facilities must often 
purchase multiple estimating and photo- imaging systems, creating redundant costs 
and expenses and lost time from having to re-enter data into different proprietary 
systems . 

Detail Description Paragraph : 

[0095] The electronic claim file repository (Eclaim database) 280 is a central 
repository for claim related and transactional data. In one embodiment, claim data 
including administrative information related to insurance policies, policy holders 

(such as name, address, policy information, and transactions) , consumers, and other 
users (e.g., insurance carriers, and vendors), as well as estimates, digital 
images, supplements, status of tasks related to the claim, and reports, is stored 
in the Eclaim database 280. The Eclaim database 280 is more fully described below. 

Detail Description Paragraph : 

[0118] The automated payment system (APS) automates the process of fulfilling 
payments required to fulfill an asserted claim by an insurance company. APS 
receives payment requests made, validates the claim under which the request is 
made, validates the request and automates payment. In the case of reception of an 
estimate, APS may make progress payments according to insurance carrier business 
rules. At step 437, APS determines if the service provider is a trusted trading 
partner. In one embodiment, this is done by using the service provider specific 
data from the system 30' s service provider directory database 290 or on the eclaim 
database 280. If the service provider is trusted, and the business rules authorize 
progress payments, the APS directs that Trust/Bank system 90 to release portions of 
payment outstanding of the total claim on a continuum that is stipulated by the 
business rules to match the progress of the service. When the service provider is 
not trusted, payment is reserved until services are completed. 

Detail Description Paragraph : 

[0125] In one embodiment, each of the sub-systems automates claims processing tasks 
to a variable degree depending on business rules . Business rules can require that, 
in response to certain data conditions, a claims processing task be turned over to 
a human participant such as an insurance adjuster. For example, if the audit sub- 
system 240 determines through comparison with actuarial analysis of stored claim 
data on past claims that a claim submitted or an estimate submitted is likely 
fraudulent, the audit sub-system 240 would notify a Special Investigating Unit 
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(SIU) of the potential fraud and assign the task of estimate review to the SIU. 
Even in a fully automated mode of operation, according to insurance carrier 
business rules, the sub- systems enable human intervention and exception handling 
for certain circumstances. 

Detail Description Paragraph : 

[0139] In step 508, FNOL 210 will verify if the policy is valid. In one embodiment, 
this is done by accessing the insurance carrier's system 65 to retrieve the policy 
profile information including policy and coverage data and then comparing it with 
the data entered. In another embodiment, the policy profile information necessary 
to validate the user's claim is stored on the eclaim database 280. If the policy 
information necessary to validate the user's claim is stored on the insurance 
carrier system 65 and FNOL 210 is unable to connect with the insurance carrier 
system 65 to confirm and potentially retrieve the necessary insurance policy 
information, FNOL 210 can continue to capture claim information, store the claim 
information received, but will not be able to complete the transaction nor assign a 
claim number until FNOL 210 is able to connect to the insurance carrier system 65 
to confirm that the policy information matches a valid insurance policy. 

Detail Description Paragraph : 

[0140] If the policy is not valid (e.g., there is no record of the insurance policy 
being asserted or the date of the loss is outside of the policy coverage period) , 
an error message will be returned to the user and the user will be given additional 
opportunities to enter valid policy information. For example, the policy 
information may have been entered incorrectly and no matching policy exists. If 
valid policy information is still not entered after a set number of attempts, e.g., 
5, the user will be informed that an error has occurred, that the user should 
contact the insurance carrier, and will be given 510 the insurance carrier's 
contact information. FNOL 210 also determines if the policy information entered 
violates insurance carrier business rules and automatically implements actions 
stored to handle such violation (e.g., if the date of loss is outside of the policy 
period, then FNOL 210 communicates to the user that the user should contact the 
insurance carrier and provides the insurance carrier's contact information). In one 
embodiment, after the claim is initiated the consumer is asked to identify what 
type of loss they wish to report (e.g., automobile, life, renters, health, and 
homeowners) . This information will help to funnel off claims that are not be 
appropriate to report through FNOL 210 and may help with the triage sub-system 220 
and assignment sub-system 230 described more fully below. 

Detail Description Paragraph : 

[0141] If the policy information entered in step 508 is valid, the user is 
presented with a second set of questions to fill out and submit. In one embodiment, 
certain policy data that relate to insured vehicles, drivers, and coverage, which 
are stored on the insurance carrier's system is retrieved and used to pre-populate 
corresponding data fields within the second set of questions the user is presented 
with . 

Detail Description Paragraph : 

[0149] In one embodiment, FNOL 210 presents distinct user interfaces to user 
according to type of user. A different user interface is presented to and utilized 
by commercial participants, e.g., agencies or call centers (carrier operated or 
outsourced) as compared with policy holders and consumers. The user interface is 
tailored to the user type, with the interface for commercial application provides 
increased functionality over the one for consumers. 

Detail Description Paragraph : 

[0160] In one embodiment, FNOL 210 interactively questions user to graphically 
represent the degree of damage a vehicle has sustained. Through a series of 
questions separated by feedback graphical representations of the user's answers, 
FNOL 210 assists the user in creating an accurate graphical depiction of a damaged 
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vehicle. FNOL 210 presents a user with a question as to what damage, the location 
of damage, and the degree of damage a vehicle has sustained. In addition, FNOL 210 
provides guidelines, in the form of text or in the form of representative graphics 
or digital photographs or images as examples of types and degree of damage 
according to location and severity. In a further embodiment, graphics or digital 
images can be produced which match or are similar to the make and model of the 
vehicle whose damage is being graphically represented. Graphics can be two- 
dimensional or three-dimensional. 

Detail Description Paragraph : 

[0162] In another embodiment, user described damage is matched with a digital 
library with images of damaged vehicles. Images that are determined to resemble the 
damage reported by the user are retrieved and presented to the user for comparison . 
If available, vehicle make and model criteria can be searched and matched to return 
digital images of damage vehicles of the same make, model and potentially year as 
the vehicle the user is attempting to describe. In another embodiment, the user is 
presented with slide bars to represent the degree of damage and can control the 
location of the damage by the reporting the angle from which the vehicle was 
damaged (e.g., one o'clock, 12 o'clock). 

Detail Description Paragraph : 
[0221] I. Profile Matching 

Detail Description Paragraph : 

[0222] First, the assignment sub-system 230 checks 1111 the profile of assignees of 
the type designated by the triage sub-system 220. The assignment sub-system 230 
checks the profiles of assignees to match insurance claim data (e.g., owner address 
or vehicle location) to a group of specific potential assignees of the determined 
type according to insurance carrier business. Assignee profile information (e.g., 
name, function, address, customer satisfaction index (CSI) score, and rates 
charged) is stored in the directory database 290, which contains profile 
information on potential assignees. In an alternate embodiment, assignee profile 
information is stored on an external database, such as an insurance carrier system 
65 database, accessible to the assignment sub-system 230. In one embodiment, the 
CSI score is one component in an assignee's profile is generated by and provided by 
the CSI sub-system 260. 

Detail Description Paragraph : 

[0223] The assignment sub-system receives the profiles for each type of assignee 
designated by the triage sub-system 220 to which to assign the claim. Specific 
claim data elements from the claim record will be checked with profile data for 
each assignee that the insurance carrier has selected as assignment criteria in 
accordance with insurance carrier business rules. Those assignees of the specific 
type that match the profile will be selected. 

Detail Description Paragraph : 

[0224] As a specific example, a business rule may be that only assignees of a given 
type who are within 50 miles of the vehicle location may be assigned a repair 
assignment. The assignment sub-system 230 then retrieves the vehicle location, 
which is piece of claim data and matches that with the store location for assignees 
of the given type according to the business rule of being within 50 miles of the 
vehicle. All assignees that match those criteria are retrieved. As a further 
example, to differentiate between assignees of the given type who meet the first 
business rule, the potential assignees that are retrieved can be ranked or can be 
further narrowed down based on CSI score, average rates, and average cycle times, 
which are generated by the reports sub-system 270 and added to the assignee profile 
in the directory database 2 90. 

Detail Description Paragraph : 

[0226] The directory database 290 can be grouped by type of assignees (e.g., repair 
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facilities, independent appraisers, rental providers) and contain standard 
administrative information such as assignee names, addresses, and phone numbers. In 
one embodiment, the directory data is retrieved from electronic yellow pages. In 
one embodiment, in addition to administrative information, the directory database 
290 stores information such as maps to the assignee location, work rates, as well 
as such information as CSI index scores, status/capacity to work, which can be 
updated by the assignee or estimated using reports such as cycle time and the 
number of assignments currently made to the assignee as are generated by the 
reports sub-system 270 and also stored to the assignee profile. Reports generated 
by the reports sub-system that are vendor specific (e.g., a particular vendor's 
cycle time (average time to complete an assignment) or an the aggregate number of 
assignments a particular vendor has be assigned over a particular period of time) 
are stored in the directory database 290. In one embodiment, vendor specific data 
such as vendor specific reports are linked to the eclaim database 280. In one 
embodiment, the directory database 280 interfaces with insurance carrier systems 
65. 

Detail Description Paragraph : 

[0266] The audit sub-system 240 periodically reviews stored claim data applies 
insurance carrier established and editable business rules to determine if any 
pieces of claim data do not meet the criteria set by the business rules . If any 
pieces of claim data do not meet insurance carrier criteria, the audit sub-system 
240 can automatically direct an action set by the business rules to resolve the 
violation, or notify a human participant such as an insurance carrier adjuster, of 
the failure. The audit sub-system 240 is able to detect and direct resolution of 
claim processing that was incorrect, processes that need to be conducted but were 
not, unreasonable estimates, and potentially fraudulent transactions. 

Detail Description Paragraph : 

[0267] As audit sub-system 240 finds situations that match the rules established by 
a particular insurance carrier, it will act upon those findings accordingly. 
According to certain business rules, the audit sub-system 240 can remove claims 
from the automated process and refer them back to the insurance carrier for 
personal attention or could continue through the automated process with 
notification going back to the carrier for informative purposes. The audit process 
could be a matter of finding certain flags, running the information past another 
database and then, based on those findings, either continuing on with the process 
or referring it back to the insurance carrier. The audit subsystem 240 could also 
be set to notify a carrier whenever certain trends are detected. For example, if a 
certain repair facility's average cost per estimate had increased more than a 
certain % in a certain amount a time, a notification could be sent to the carrier 
for them to further investigate the causes. Again, the audit sub-system 240 looks 
for exceptions to the standard, accepted procedures or practices that the insurance 
carrier has established in the form of business rules. 

Detail Description Paragraph : 

[0271] The audit sub-system 240 processes 1803 retrieved or received claim related 
data according to business rules designated by an insurance carrier. Business rules 
are editable and updateable at the direction of the insurance carrier. Through 
application of insurance carrier business rules to the claims data, the audit sub- 
system 240 determines 1805 if any business rules are violated . For example, if a 
business rule is that only used parts should be used to the repair vehicles made in 
1995 or earlier, and an estimate submitted by a repair facility references to use 
of new parts for repair of a 1990 vehicle, the audit sub-system 240 would 
automatically detect that the repair facility's estimate had violated a business 
rule . 

Detail Description Paragraph : 

[0274] If no business rule or statutory regulation has been violated, the audit 
process terminates 1809. If a business rule or statutory regulation violation is 
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detected, the audit sub-system 240 applies business rules to process the violation . 
The audit sub-system 240 can directly notify third parties involved (e.g., vendors 
or policy holders) of the violation with explanation as to reason for violation and 
proposed courses of action. For example, if an estimate submitted by a repair 
facility provides insufficient or invalid information, the audit sub-system 240 
would detect the violation and notify the repair facility to complete or provide 
additional valid information. Violations resolution is governed by business rules 
and can require that the audit sub-system 240 notify and transfer the audit process 
to a human participant such as an insurance carrier appraiser. For example, if 
instead of determining that an estimate submitted by a repair facility violates 
business rules by failing to submit sufficient or valid information, the audit sub- 
system 240 determines that the estimate contains sufficient and valid information, 
but is unreasonably high, the audit sub-system 240 would assign the audit process 
to an human participant such as an insurance carrier adjuster to conduct an 
additional audit, and if the estimate is still found unreasonable, to negotiate 
with the repair facility to change the estimate. In an alternate embodiment, in the 
previous example, the audit sub-system 240 could automatically notify the repair 
facility that their estimate was denied, that it was unreasonable, and with 
sufficient details of denial such that the repair facility can attempt to make a 
more reasonable estimate. 

Detail Description Paragraph : 

[0277] In one embodiment, the audit sub-system 240 applies trending analysis to 
claim data to determine if the claim data falls outside of normal boundaries. For 
example, instead or in addition to applying a business rule that lists 
circumstances (e.g., the cost of a hood is within a certain range) in estimates 
that would result in the estimate being determined unreasonable, the audit sub- 
system 240 can apply trending analysis data that can be stored in the eclaim 
database 280 or generated by the reporting sub-system 270. For example, the 
reporting sub-system could determine how much the last 100 repair facilities 
charged for the repair of the left front door of a specific vehicle make, model and 
year. If claim data of a newly submit estimate for a comparable task is retrieved 
by the audit sub-system 240, the audit sub-system 240 applies the report to 
determine if the estimate is unreasonable for falling outside of the ranges. 

Detail Description Paragraph : 

[0279] Upon termination of the audit process, either through no violation of 
business rules or statutory regulations being found, or if a violation was found, 
the audit sub-system 240 rectifying the violation according to business rules, the 
audit sub-system 240 notifies the sub-system or systems that it operates directly 
in conjunction with (e.g., the eclaim database 280 and the insurance carrier system 
65) of the result of the audit process and logs an entry of the decision and 
details related to the decision to those system (s) . In one embodiment, the audit 
sub-system 240 notifies a third party (e.g., a vendor or a policy holder or 
consumer) that does not interact directly with the audit sub-system 240 of the 
audit sub-system 240s conclusion. For example, if the audit sub-system 240 audits 
an estimate submitted by a repair facility and determines does not approve the 
estimate, the audit sub-system 240 notifies the repair facility that the estimate 
was denied. 

Detail Description Paragraph : 

[0315] In the case of progress payment requests, the APS 250 can determine based on 
the insurance carrier's business rules if the request matches a progress milestone 
or fulfills some other criteria. In one embodiment, progress payments may be 
processed automatically without requiring the payee 2605 to make a payment request. 
For example, a business rule may allow APS to automatically pay a DRP member whose 
has a fast average cycle time of repairs a portion of repair fees proportionate to 
the time since the assignment was made and the current date. For example a DRP who 
has shown, on average, that a certain task assigned to it requires ten days for the 
to complete, would be paid 50% of the estimated repair fees five days after the 
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assignment was made. 

Detail Description Paragraph : 

[0325] APS 250, based on insurance carrier business rules, determines payment 
execution dates. The APS 250 directs 2713 the trustee bank 2603 to execute a single 
or batch of payments to fulfill a single or multiple payment requests on the 
payment execution date, which can be the same date APS places to order to execute 
or can be a date different from the date APS places to order to execute. The 
trustee bank 2603 executes orders that it has previously received payment 
information for, and for which the trustee bank 2603 has received sufficient funds 
to cover the disbursement from the insurance carrier bank 2601 prior to the payment 
execution date of the order. In another embodiment, if the trustee bank 2603 does 
not receive funds matching the execution amount, the trustee bank 2603 may still 
execute payment execution orders based on previously received funds that are 
sufficient to cover the disbursement or through drawing down on an insurance 
carrier's line of credit, which is not, nor will be overdrawn by the execution of 
the payment (s), with the trustee bank 2603, if an insurance carrier has such a line 
of credit with the trustee bank 2603. 

Detail Description Paragraph : 

[0329] The trustee bank 2603 provides electronic notification to the APS 250 that 
payment has been made to the payees 2605. APS notifies 2715 the payee 2605 that 
payment has been executed. Once the payments have been made and the payees 2605 
have been notified, the APS 250 updates 2715 the eclaim database 280 with the 
details of the payment. In another embodiment, once the payments have been made and 
the payee 2605s have been notified, the insurance carrier system 65 is updated with 
payment details to reflect the payment. In one embodiment, an entry of the payment 
is logged in the transaction record stored of the eclaim database 280. 

Detail Description Paragraph : 

[0352] In addition, customer satisfaction reports can be generated by the reports 
sub-system 270 for the survey data. Reports can be generated daily, weekly, 
monthly, quarterly, and yearly reports on customer satisfaction and include reports 
that aggregate industry ratings for benchmarking ( comparison with the performance 
of other commercial participants) and graphical reports. 

Detail Description Paragraph : 

[0362] In another embodiment, the reporting sub-system supports the generation of 
customized reports that match user selected criteria to produced focused results. 
The reporting sub-system is able generate reports indexed by activity within a 
specific time range, by activity within a geographical region, and by vehicle type. 
FIG. 29 is a screenshot of a report generated by a reporting sub-system that is 
indexed by region and by state within each region. In one embodiment, the reporting 
sub-system 270 allows a user to drill down and view the specific details of 
customized reports (e.g., the number of assignments can be presented in a per day, 
per adjuster, per week, per month, per quarterly and per year format, or by 
adjuster, by service office, by region, and by insurance carrier) . In one 
embodiment, customized reports are generated by third party systems. 

Detail Description Paragraph : 

[0363] Reports can be generated to analyze and compare trends in the processing of 
claims. For example, the average estimate for a certain type of repair over a 
current quarter, the month prior to the current quarter, the quarter prior to the 
current quarter, and the year prior to the current quarter. These trend-analyzing 
reports can provide an insurance carrier with data to determine if subsequent 
estimates for similar types of repair are reasonable or even potentially 
fraudulent. Reports can be generated real time at the point of request or at set 
times with the results being stored in the eclaim database 280, the directory 
database 2 90, or the insurance carrier system 65. 
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CLAIMS : 

1. A computer implemented method of capturing initial insurance claim data 
comprising: receiving an insurance claim; determining the type of user initiating 
the insurance claim; presenting the user with a first plurality of questions 
regarding an insurance policy under which the claim is being submitted depending on 
the type of user ; determining if the claim is covered under a valid policy; 
retrieving profile information of the user that relates to the claim and pre- 
populating a subset of a second plurality of questions with the profile 
information; presenting the user with the second plurality of questions regarding 
the insurance claim in which a subset of questions subsequent to an initial subset 
of questions presented in the second plurality of questions vary depending on the 
user ' s answers to the initial subset of questions, where both the initial and 
subsequent subset of question vary according to the type of user ; storing the 
answers to the first and second plurality of questions in a data format that is 
useable by an insurance claim system. 

7. The computer implemented method of assigning a task associated with an insurance 
claim to at least one of assignees, the method comprising: determining a plurality 
of potential assignees that handle the task associated with the insurance claim of 
a determined class from a database containing a plurality of assignees by matching 
a profile of an assignee with a profile of the determined class; scoring each 
profile of the plurality of potential assignee that handle the task of the 
determined class according to the application of business rules to the data 
elements; selecting the most highly scored potential assignees; determining the 
capacity of each of the highly scored potential assignees to accept the task; 
assigning the assignment to a number of assignees that have the greatest capacities 
to complete the assignment. 

12. A computer implemented method for auditing a plurality of data associated with 
an insurance claim to determine if the insurance claim has been accurately 
processed comprising: receiving a plurality of data, which includes initial claim 
data, a transaction history of the claim, estimates, and payment requests; 
comparing the received data representing the transactional history of claim 
handling to governmental regulatory requirements to determine if additional action 
is required; comparing the received data representing the transactional history of 
claim handling to a plurality of business rules to determine if additional action 
is required; determining from application of a plurality of business rules to the 
received data representing generated estimates whether to validate the estimate and 
if there is a potential for fraud; determining from the application of a plurality 
of business rules to the received data representing payment requests whether to 
validate the payment request and if there is a potential for fraud. 
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